Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stage 2 changes for RFC 0018 - extending the threat.* field set #1438

Merged
merged 4 commits into from
May 27, 2021

Conversation

ebeahan
Copy link
Member

@ebeahan ebeahan commented May 26, 2021

Apply changes from stage 2 extending the threat.* header RFC (0018): #1395

Docs preview of these changes

@ebeahan ebeahan self-assigned this May 26, 2021
Copy link
Contributor

@djptek djptek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does threat.group.alias have to be an array or is a single keyword also permissible?

Copy link

@devonakerr devonakerr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One open question to address diction, though I do not believe the implication of "should" versus "may" is a significant one. Both terms suggest an exception in which an array may not have multiple values.

@ebeahan
Copy link
Member Author

ebeahan commented May 27, 2021

"Should" is used because while Elasticsearch fields can have zero or more values by default, data sources and libraries producing ECS data need to distinguish between when a field only holds a single value vs. an array of possible values even if only one value is present sometimes ("dog" vs. [ "dog" ]).

The note in the field reference is to help users implementing ECS know when to use an array construct in their implementation.

Copy link
Contributor

@peasead peasead left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ebeahan ebeahan force-pushed the rfc/0018/stage-2-beta-implementation branch from dd70bc8 to 6e2e32b Compare May 27, 2021 21:19
@ebeahan ebeahan merged commit e46c08b into elastic:master May 27, 2021
@ebeahan ebeahan deleted the rfc/0018/stage-2-beta-implementation branch May 27, 2021 21:32
ebeahan added a commit to ebeahan/ecs that referenced this pull request May 27, 2021
…astic#1438)

# Conflicts:
#	experimental/generated/csv/fields.csv
#	generated/csv/fields.csv
rylnd added a commit to rylnd/ecs that referenced this pull request May 28, 2021
* master:
  Stage 2 changes for RFC 0018 - extending the `threat.*` field set (elastic#1438)
  Remove deprecated `host.user.*` fields (elastic#1439)
  Explicitly include user identifiers in `related.user` field description (elastic#1420)
  Set the merge date on RFC 0018 stage 2 (elastic#1429)
  [RFC] Extend Threat Fieldset - Stage 2 Proposal (elastic#1395)
  [Tooling] Add --exclude flag to Generator to support field removal testing (elastic#1411)
  Add `host.user.*` deprecation notice in field reuse description (elastic#1422)
  Stage 2 changes for RFC 0015 - `elf` header (elastic#1410)
  Stage 3 changes for RFC 0012 - `orchestrator` field set (elastic#1417)
  Support `match_only_text` in Go code generator (elastic#1418)
  Stage 3 Orchestrator RFC (elastic#1343)
  moving into folder (elastic#1416)
  removing use-cases (elastic#1405)
  removing --oss (elastic#1404)
  Set the merge date on RFC 0015 stage 2 (elastic#1409)
  Consolidate `Breaking changes` sections in `CHANGELOG.next` (elastic#1408)
  RFC-Stage-0: Proposal to add a "ticket" schema / field definition to ECS (elastic#1383)
  [RFC] `match_only_text` type migration - Stage 0 (elastic#1396)
  Client port is wrongly documented (elastic#1402) (elastic#1406)
@rylnd rylnd mentioned this pull request Jun 15, 2021
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants